@dmn-tck/contributors please review.

Reviewed and test pass on the Trisotech Engine

The tests for numbers with exponent are correct. However, there is a flickering test:

    <decision name="time_009" id="_time_009">
        <description>Tests FEEL expression: 'time("10:30:00+01:00") = time("10:30:00@Europe/Paris")' and expects result: 'true (boolean)'</description>
        <question>Result of FEEL expression 'time("10:30:00+01:00") = time("10:30:00@Europe/Paris")'?</question>
        <allowedAnswers>true (boolean)</allowedAnswers>
        <variable name="time_009"/>
        <literalExpression>
            <text>time("10:30:00+01:00") = time("10:30:00@Europe/Paris")</text>
        </literalExpression>
    </decision>

The offset of @Europe/Paris varies during the year (e.g. winter time vs summer time) hence the issue.

The issue with appending zone ids to time literals was discussed both here and in the RTF meeting. Here we agreed to ban the usage of zone ids for time literals. In DMN 1.6 this use case was deprecated as adding the zone id does not make sense as the date is not known.

I propose removing the test either here or in another PR.

Also, we need to discuss the equality tests for ranges according to the DMN 1.5 spec.

For example, range_006: (< 10) = (null..10). According to the spec, the semantics of these two is different when evaluated in the same context, e.g. 5 in X (see Table 42 in Section 10.3.2.7 Ranges). Also, according to the examples in Table 62

(< 10) is the same with (..10)

A missing/undefined endpoint is not the same as being null. When the endpoint is missing it is ignored when building the equivalent logical expression. When the endpoint is null, the result is null (error as null is compared to a comparable value)

We cannot have A = B when A and B produce different results in the same expression. It is against the substitution principle.

From discussion on the meeting - let's remove the test with time with a timezone.

test removed

As this PR is already for the equality suite, I've amended the equality checks here for unary comparison ranges as per discussions here: #663

@dmn-tck/contributors please re-review after the updates.

Looks good to me.